OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skipauthroutes and skipauthregex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trustedproxyip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.

OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 have a configuration-dependent authentication bypass. Deployments are affected when all of the following are true: Use of skipauthroutes or the legacy skipauthregex; use of patterns that can be widened by attacker-controlled suffixes, such as ^/foo/./bar$ causing potential exposure of /foo/secret; and protected upstream applications that interpret # as a fragment delimiter or otherwise route the request to the protected base path. In deployments that rely on these settings, an unauthenticated attacker can send a crafted request containing a number sign in the path, including the browser-safe encoded form %23, so that OAuth2 Proxy matches a public allowlist rule while the backend serves a protected resource. Deployments that do not use these skip-auth options, or that only allow exact public paths with tightly scoped method and path rules, are not affected. A fix has been implemented in version 7.15.2 to normalize request paths more conservatively before skip-auth matching so fragment content does not influence allowlist decisions. Users who cannot upgrade immediately can reduce exposure by tightening or removing skipauthroutes and skipauthregex rules, especially patterns that use broad wildcards across path segments. Recommended mitigations include replacing broad rules with exact, anchored public paths and explicit HTTP methods; rejecting requests whose path contains %23 or # at the ingress, load balancer, or WAF level; and/or avoiding placing sensitive application paths behind broad skipauthroutes rules.

Impact A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

- OAuth2 Proxy is used with an authrequest-style integration (for example, nginx authrequest) - --ping-user-agent is set or --gcp-healthchecks is enabled

In affected configurations, OAuth2 Proxy will treat a request with the configured health check User-Agent value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.

This issue does not affect deployments that do not use authrequest-style subrequests, or that do not enable --ping-user-agent/--gcp-healthchecks.

Patches Users should upgrade to v7.15.2 or later once available. Deployments running versions prior to v7.15.2 should be considered affected if they use authrequest-style authentication together with --ping-user-agent or --gcp-healthchecks.

Workarounds Users can mitigate this issue by:

- disabling --gcp-healthchecks - removing any configured --ping-user-agent - ensuring the reverse proxy does not forward client-controlled User-Agent headers to the OAuth2 Proxy auth subrequest - using path-based health checks only, on dedicated health check endpoints

Example nginx mitigation for the auth subrequest:

nginx location = /oauth2/auth { internal; proxypass http://127.0.0.1:4180; proxypassrequestbody off; proxysetheader Content-Length ""; proxysetheader Host $host; # set to value that isn't the same as your configured PingUserAgent or GCPs "GoogleHC/1.0" proxysetheader User-Agent "oauth2-proxy-auth-request"; }

Impact A regression introduced in v7.11.0 is preventing OAuth2 Proxy from clearing the session cookie when rendering the sign-in page.

This only impacts deployments that rely on the sign-in page as part of their logout flow. In those setups, a user may be shown the sign-in page while the existing session cookie remains valid, so the browser session is not actually logged out. On shared workstations be it browsers or devices, a subsequent user could continue to use the previous user's authenticated session.

Deployments that use a dedicated logout/sign-out endpoint to terminate sessions are not affected.

Patches This issue is fixed in v7.15.2.

Workarounds Do not rely on the sign-in page to clear an existing session. Instead:

- Use the dedicated logout/sign-out endpoint of OAuth2 Proxy - Ensure your application logout flow explicitly clears the OAuth2 Proxy session cookie before redirecting users to the sign-in page - If needed, clear the session cookie at the reverse proxy or application layer as a temporary mitigation

Impact All deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications).

Authenticated users can inject underscore variants of X-Forwarded- headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised.

Patches

This change mitigates a request header smuggling vulnerability where an attacker could bypass header stripping by using different capitalization or replacing dashes with underscores. The problem has been patched with v7.13.0.

By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores () versus dashes (-) will be ignored when matching headers to be stripped. For example, both X-Forwarded-For and XForwarded-for will now be treated as equivalent and stripped away.

However, if users have a rationale for keeping a similar-looking header and don't want to strip it, a new configuration field for headers managed through AlphaConfig called InsecureSkipHeaderNormalization has been introduced :

golang // Header represents an individual header that will be added to a request or // response header. type Header struct { // Name is the header name to be used for this set of values. // Names should be unique within a list of Headers. Name string json:"name,omitempty"

// PreserveRequestValue determines whether any values for this header // should be preserved for the request to the upstream server. // This option only applies to injected request headers. // Defaults to false (headers that match this header will be stripped). PreserveRequestValue bool json:"preserveRequestValue,omitempty"

// InsecureSkipHeaderNormalization disables normalizing the header name // According to RFC 7230 Section 3.2 there aren't any rules about // capitalization of header names, but the standard practice is to use // Title-Case (e.g. X-Forwarded-For). By default, header names will be // normalized to Title-Case and any incoming headers that match will be // treated as the same header. Additionally underscores () in header names // will be converted to dashes (-) when normalizing. // Defaults to false (header names will be normalized). InsecureSkipHeaderNormalization bool json:"InsecureSkipHeaderNormalization,omitempty"

// Values contains the desired values for this header Values []HeaderValue json:"values,omitempty" }

Workarounds Ensure filtering and processing logic in upstream services don't treat underscores and hyphens in Headers the same way.